home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0058.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.7 KB  |  128 lines
  1. [Admin: If anyone is missing documents from this discussion which I  
  2. have, they are all in a mailbox  
  3. file://info.cern.ch/pub/www/doc/udi/discussion.mbox. Some of the  
  4. messages were sent to only some of the lists.  Also, I mis-spelled  
  5. the name of cni-arch.uccvma in my original posting, so some replies  
  6. have not gone there. I will not repost them.  The orginal udi paper  
  7. is slightly updated now. Same UDI -- no versioning ;-)]
  8.  
  9. Now, about these USDNs:
  10.  
  11. > Date: Thu, 5 Mar 92 07:32:50 EST
  12. > From: ses@cmns.think.com
  13.  
  14. There have been several messages now with a common theme: That what I  
  15. called in the udi1 paper a "lasting registered name" is better than  
  16. an "address".
  17.  
  18. Peter Deutsch argues the point at length in  
  19. <9203042206.AA12411@expresso.cc.mcgill.ca>, using the term USDN by  
  20. analogy with ISBN.
  21.  
  22. John Curran on <Thu, 27 Feb 92 19:45:42 -0500> argues the same, and  
  23. also suggests quoting both registered name and address (which I  
  24. wasn't so sure about in case they get out of sync).
  25.  
  26. I completely agree with Peter and Simon's point of view, and I have  
  27. modified the paper to put more emphasis on this. What I obvioulsy  
  28. didn't make clear enough is my feeling that:-
  29.  
  30. 1.There may be more than one USDN scheme, just as there are many  
  31. physical addres schemes.
  32.  
  33. 2. There may be more than two stages: it is  an oversimplifiaction to  
  34. talk of only a USDN and an address: For example, an ISO standard may  
  35. dereference (or as Ed says, "swizzle") to a document produced by the  
  36. IETF which may dereference down to a prospero name which may be a  
  37. pointer to an FTP file.
  38.  
  39. 3. We can't use USDNs now because they aren't there. We need a  
  40. transision strategy.
  41.  
  42. Therefore, UDis were supposed to be able to hold _either_ a USDN _or_  
  43. a physical address. They weren't intended to get involved with the  
  44. discussion of which USDN/ISBN/ISSN/ISDN (?!) scheme is better. So, I  
  45. say, by all means define an USDN scheme, then register it as a  
  46. possible UDI. If is good and everybody uses it, everything will end  
  47. up with a USDN, and the context will always be USDN documents, so the  
  48. usdn: prefix (or whatever) will not in practice be used. I'm all for  
  49. the market deciding between protocols.
  50.  
  51. Simon:
  52.  
  53. > I'm strongly in favour of the two stage lookup process; X.500 is  
  54. obvious
  55. > technology, although it is rather heavyweight for personal  
  56. computers. An 
  57.  
  58. > alternative might be some sort of DNS/archie-like service. These  
  59. could return
  60. > Tim's UDIs, which could then deliver the good themselves.
  61.  
  62. I would say "a server takes x500 UDIs and returns physical UDIs which  
  63. deleiver the goods themselves.", meaning the same thing.  (I would  
  64. allow it the option of delivering a set of addresses, not just one.)  
  65. Yes, x500 is heavyweight so one can have a lighter protocol which  
  66. accesses a real x500 engine via a gateway with a large cache.
  67.  
  68. > Of course, invdidual information sources should still use local  
  69. document 
  70.  
  71. > numbers where possible, but should provide a way of mapping from  
  72. local-id
  73. > to universal-id when needed.
  74.  
  75. Yes.
  76.  
  77. > One little question: What should be done about document versions?
  78. > Obviously, different versions of a document should have different
  79. > UDSNs, but should there be a simple way to compare USDNs modulo
  80. > versions? 
  81.  
  82.  
  83. Good point.  What about versions which split?  A great spin-off of  
  84. having versions available is that you can refer to a line number in  
  85. them. A line number in a document which is not frozen is useless.  
  86. [This solves a recurring problem in hypertext systems, when one wants  
  87. to link to part of a document to which one has no write access, and  
  88. which may change].
  89.  
  90. > Here are some suggestions.. Eat hot ASN, Cultural Cringer.
  91. > [...]
  92.  
  93. We must be careful not to reinvent the wheel: if the USDN problem is  
  94. the same as the phone book problem (which it seems to be) then we  
  95. should pick up on x500.
  96.  
  97. An important thing about x.500 is that it was designed to scale (I  
  98. hope!).  By contrast as Ed says:
  99.  
  100. | Date: Wed, 04 Mar 92 23:52:05 -0500
  101. | From: Edward Vielmetti <emv@msen.com>
  102. | [...]
  103. | ISBN is hierarchical so you can stamp out your own
  104. | unique ID's; ISSN (international standard serial number) has
  105. | a central cataloging authority.
  106.  
  107. and i doubt whether either of those will scale to allow document  
  108. publishing on the net by every kindergarten child etc etc twice a  
  109. minute. That's why I assume x500 is best in theory at least. But tell  
  110. me I'm wrong.
  111.  
  112. Ed also mentions message-ids which are after all unique. The trouble  
  113. is, there's no way of looking up where to find them.
  114.  
  115.     Tim
  116.  
  117. __________________________________________________________
  118. Tim Berners-Lee                       timbl@info.cern.ch
  119. World Wide Web initiative             (NeXTMail is ok)    
  120. CERN                                  Tel: +41(22)767 3755
  121. 1211 Geneva 23, Switzerland           Fax: +41(22)767 7155
  122.  
  123.  
  124.  
  125. 
  126.  
  127.  
  128.